Object oriented component and framework architecture for signal processing

ABSTRACT

A reconfigurable distributed signal processing system uses an object-oriented component-framework architecture in which the system permits large-scale software reuse. This is accomplished by the use of a framework and a number of reusable, reconfigurable software components that are hardware independent. The components communicate over a data fabric using open published APIs over one or more data communications mechanisms. Interchangeable software components are used that perform the signal processing. Interchangeability is assured by each component meeting a required interface in which the component inherits the required interface elements from component base classes. This use of inheritance to assure interface compliance also reduces the programming work required for developing a component. Most importantly, the interchangeable components are reconfigurable into various systems at runtime, as defined by a Plan. A Plan is a schematic of the configuration of the various components to be used to solve a particular signal processing problem which includes the list of components, what computer each component is to execute on, how the components are interconnected, and the initial parameter values of the components. The system functionality and capability can be reconfigured at runtime based on a Plan read by a software element of the framework, the Framework Manager. Moreover, the source code for the components is platform independent. The system is able to use heterogeneous commercial off-the-shelf hardware to minimize equipment costs and lower non-recurring engineering costs as well. The system uses the object-oriented programming and software development to reduce time to market and to ensure program success while at the same time exploiting a standard development methodology.

FIELD OF INVENTION

[0001] This invention relates to distributed signal processing systemsand more particularly to the use of object oriented techniques toprovide a reconfigurable signal processor.

BACKGROUND OF THE INVENTION

[0002] Historically, signal processing has been performed using acombination of special purpose hardware and software designed for thespecific digital signal processor environment used in a particularapplication. At times when no real-time operating system was available,the programmer had to be concerned with every detail of memorymanagement, communications and scheduling. Even when real-time operatingsystems such as VxWorks have been available, the signal processingprogrammer typically needed to be concerned about the specific memory,input/output, and communications architecture of the processor used.

[0003] As a result, signal-processing software was difficult to reuse.In the past, signal processing has placed strong demands on processingthroughput, often approaching the entire processing capacity of thecomputer or computers used. To maximize performance for the capabilityof a given computer or set of computers, the design and implementationof the signal processing software was closely tied to the particularhardware architecture and was also closely tied to the particularoperating system and related libraries previously developed. Hence,reuse was difficult due to the fact that this signal processing softwarewas closely tied to the particular hardware architecture and operatingsystem used. This signal processing software required optimization for aparticular application and was designed for specific functionalityrather than to comply with an overarching architecture for reuse.Presently, due to the complex nature of signal processing tasksinvolved, specialized equipment and software is developed for each andevery one of the signal processing requirements. What results is amultiplicity of processor types, a multiplicity of operating systems,and a multiplicity of hardware components, none of which are reusablefrom one application the other.

[0004] With the advent of more capable general-purpose processors andoperating systems, whether real-time or not, it became possible toconsider a more general and reusable approach to signal processing.

[0005] Many vendors now provide computer modules in the form of cardswith one or more processors, memory, and input/output with highperformance and integral communications capabilities. Thesecommunications are often provided by dedicated hardware on the computermodules and are usually designed to be scalable so that as modules areadded to the system, the communication bandwidth is also increased.However, generally these computer modules are dedicated to one specifictype of operating system and related libraries. The task of reusingsignal processing applications when converting from one computer moduleto another, particularly between different vendors, remains a difficult,time consuming, and expensive task.

[0006] There is therefore a need to find means to exploit modernhardware and software engineering approaches to define an architecturefor signal processing that would allow for software reuse and rapidsystem development owing to that reuse. It is also important that thearchitecture developed not be tied to any particular processor type orhardware so that one can quickly take advantage of processorimprovements, or at least not fall victim to the disappearance of aparticular processor type or hardware from the commercial marketplace.

[0007] For instance, in an airborne communication, command, and controlpayload, there are various functions that such a system must perform.These include a communications relay function, signals intelligenceprocessing function, acoustic signal exploitation function, andidentification of friend-or-foe function. In the past, each of thesefunctions required a separate set of processors and specializedhardware. The payload system integrator was required to incorporate inthe equipment bay a number of highly independent sub-systems ofspecialized equipment, because common equipment could not be reused orreconfigured to provide the required functionality. In the equipmentperforming the signal intelligence processing, one needs to have areceiver interface, a signal energy detection system, signal recognitioncapability, radio direction finding capability and a countermeasuresystem that can include jamming. Each of these functions was priorlyperformed by separate processors and specialized hardware. It isinteresting to observe that the a communications relay function,acoustic signal exploitation function and identification offriend-or-foe function require similar, if not identical capabilities.

[0008] In the past, in order to accomplish each of the above-namedfunctions where one has very limited payload restrictions, the payloadequipment and software was selected prior to flight in which only onecapability was permitted per mission. It is desired to be able to reusevarious processing capabilities and hardware capabilities for multipletasks, permitting multiple capabilities per mission.

[0009] Thus, one of the major problems with writing software for signalprocessing in the past has been the inability to reuse software thatpreviously has been developed for specific applications and particularhardware suites.

[0010] Previously, distributed signal processing applications were sodemanding that they were written to be tightly coupled to a particularcomputer platform, a particular operating system, and the communicationsinfrastructure that was being used. Reuse for different applications wasvirtually impossible. Further, when the computer platform changed or thecommunication infrastructure changed, that software had to bere-written.

SUMMARY OF THE INVENTION

[0011] In order to solve the problem of having signal processingperformed using a combination of special purpose hardware and softwaredesigned for the specific digital signal processor environment used in aparticular application, in the subject invention, an object-orientedsystem or architecture is used to provide an overarching architecturefor reuse. With the advent of more capable general purpose processorsand operating systems, whether real-time or not, the subject systemmakes it possible to consider a more general and reusable approach ofsignal processing.

[0012] As a result, in the subject invention, object-orientedcomponent/framework architecture is used with several key attributes.

[0013] The first is that the framework provides many underlyinginfrastructure capabilities needed by signal processing systems such asvarious means of communication, code downloading, processing control,error logging and other functions.

[0014] Secondly, the framework is layered so that the details of theinterface to the hardware, processors and communications are isolated inspecific layers. The signal processing application software in the upperlayer is isolated from the operating system, communicationinfrastructure, and processor hardware. This localizes any changes inthe system required for easy porting to new processors to the lowestlayers, and as a result, investment in the signal processing applicationis preserved.

[0015] Thirdly, signal processing techniques and algorithms areencapsulated in components that perform their individual functionswithout explicit dependency or direct interaction with any othercomponents in the system. This makes the designed component highlymodular and more reusable. Each component must meet the requiredinterfaces to the framework to ensure proper operation of the overallsystem.

[0016] Fourthly, all components take advantage of the object-orientedapproach to inherit much of their capabilities from component baseclasses that provide commonly needed capabilities to fit into theframework and overall system architecture. This approach facilitatesrapid development for new components from direct reuse of much commonsoftware code. Further, these component base classes provide theinterface between the components and the interface from the componentsto the framework, relieving the burden of complying with theseinterfaces from the software component developer.

[0017] Fifthly, the framework and component approach embodies astandardized signal or streaming-data processing architecture toimplement many different signal or streaming-data processingapplications. In order to perform a specific processing application,reusable and reconfigurable software components are deployed and executeon one or more interconnected computers. Each of these processors iscoupled to a data communication fabric that provides interconnection ofmessages from each processor. In typical embodiments these are buses,switched circuits, or combinations of both. Each computer has aProcessor Manager, an executable program part of the framework whichorchestrates framework infrastructure services for that particularcomputer and the components that execute there. The entire signalprocessing system is under the governance of a Framework Manager,another executable part of the framework that deploys, connects and runsthe components in accordance with a Plan. The Plan defines the signalprocessing task or tasks by specifying the components to be used, thecomputer or computers to execute each component, the interconnection ofthe inputs and outputs of each of the components, and the parametersthat control the behavior of each of the components.

[0018] The subject system thus meets the need to greatly increase theability to reuse software from one signal processing application to thenext. In addition it makes the process of porting to the next generationcomputing hardware a much faster and easier process. By contrast, in thepast most applications had to be redesigned and recoded to operate oneach new hardware computation platform. It became sadly apparent that bythe time one could complete that effort, this computation platform wouldno longer be a state-of-the-art, and a time-to-market window might havebeen missed. What was therefore needed was a leapfrog technology to beable to access state-of-the-art components and to arrange them in anobject-oriented framework architecture to perform the signal processing.

[0019] The subject system defines a component-framework architecture tobe used for signal and streaming-data processing. Except for a specifichardware interface layer, it is hardware independent, and uses a modemobject-oriented approach so that the software can be reused. The subjectarchitecture also promotes portability and the ability to take advantageof rapidly evolving, highly capable, general-purpose commercialoff-the-shelf processors.

[0020] The following U.S. Patents detail object-oriented programmingframeworks and their use in applications other than signal processing:U.S. Pat. Nos. 6,424,991; 6,195,791; and, 6,308,314 In summary, areconfigurable distributed signal processing system uses anobject-oriented component-framework architecture in which the processingsystem architecture permits large-scale software reuse. This isaccomplished by the use of a reusable, layered framework and a number ofreusable, reconfigurable software components that are both highlymodular and hardware independent. The components communicate over a datafabric using open published APIs and one or more data communicationsmechanisms. Interchangeable software components are used that performthe signal processing. Interchangeability is assured by each componentmeeting a required interface; the component inherits the requiredinterface elements from component base classes. This use of inheritanceto assure interface compliance also reduces the programming workrequired for developing a component. Most importantly, theinterchangeable components are reconfigurable into various systems atruntime, as defined by a Plan. A Plan is a schematic of theconfiguration of the various components to be used to solve a particularsignal processing problem which includes the list of components, whatcomputer each component is to execute on, how the components areinterconnected, and the initial parameter values of the components. Thesystem functionality and capability can be reconfigured at runtime basedon a Plan read by a software element of the framework, the FrameworkManager.

[0021] Moreover, the source code for the components is platformindependent since all the software which interacts with the operatingsystem and the computer hardware is isolated in separate software layerswith well defined interfaces based on well-recognized industrystandards. Since the approach allows the use of multiple independenthardware and operating system interface layers at the same time, thesystem is able to use heterogeneous commercial off-the-shelf hardware tominimize equipment costs and lower non-recurring engineering costs aswell. The system uses object-oriented software development andprogramming in a well-defined architecture to enable large-scale reuseas a way to reduce time to market and to ensure program success.

[0022] The required interfaces for each interchangeable componentinclude the component-framework interface, input ports, output ports,parameters, plots, statistics, and error handling. The components do notcommunicate directly with specific other components but only throughtheir interfaces with the framework. The components themselves inheritfrom the component base classes characteristics to ensure interfacecompatibility and to dramatically reduce programming work required whendeveloping the component. The list of classes from which the componentinherits includes a component controller, a transform, input and outputports, a plot and/or statistics ports.

[0023] It will be appreciated that the subject system is platformindependent in that the component uses the Operating System ApplicationProgramming Interface, or OSAPI, not native calls, meaning that theoperating system interfaces are not used directly. Since each operatingpotentially has a different interface, instead one uses a specializedOSAPI layer that translates from a standardized interface to thespecialized interface of each native operating system.

[0024] In operation, a Plan is devised and is passed to a FrameworkManager which deploys the components to the various processors through aProcessor Manager and connects the output ports to the input ports foreach of the components, sets the component parameters, sets theparameters on the output ports, starts the particular components andmonitors the health of the system.

[0025] The subject system is therefore configurable using independent,reusable, interchangable components executing on one or more computernodes interconnected by a data fabric or bus structure to which iscoupled the Framework Manager and various processors, with the Planbeing inputted to the Framework Manager for the overall reconfigurationand control of the signal processing system. What one has achieved isthus a reconfigurable signal processing system that can be reconfiguredat runtime.

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] These and other features of the subject invention will be betterunderstood in connection with the Detailed Description in conjunctionwith the Drawings, of which:

[0027]FIG. 1 is a block diagram of the subject system illustrating theconnection of a framework manger, components, and process manager to acommunications fabric;

[0028]FIG. 2 is a block diagram showing the system of FIG. 1, showingthe interconnections of the parts logically rather than all goingthrough the communications fabric;

[0029]FIG. 3 is a diagrammatic illustration of a Unified ModelingLanguage, UML, class diagram for the structure of a component;

[0030]FIG. 4 is a UML class diagram for an example simple componentcalled TMP;

[0031]FIG. 5 is a UML class diagram showing associations for the simpleTMP component; and,

[0032]FIG. 6 is a diagrammatic illustration of the layered architectureof one embodiment of the subject invention.

DETAILED DESCRIPTION Basic Architecture

[0033] In order to provide for the subject framework architecture forsignal processing, a system 10 includes a number of components 12 and 13which are connected through a communication fabric 14 to each other andto a Framework Manager program 16, which is provided with a Plan 18 fordefining the system. Each of the components is coupled to a respectiveProcessor Manager program 20 and 22, with the components executing on anumber of respective computers 24 and 26, each computer having itsassociated Processor Manager 20 and 22.

[0034] The communication fabric permits communication between thecomponents of the Framework Manager and associated Processor Managers aswell as computers so that system can be reconfigured based on Plan 18read by Framework Manager 16.

[0035] It will be noted that each of the components have standardizedinterfaces, namely an one or more input ports 34, one or more outputports 36, parameters port 38, and a plot port/statistics port 40. Theseinterfaces are managed by objects: an input port object manages theinput port interface, an output port object manages the output portinterface, a parameters object manages the parameters, and anotherparameters object manages the statistics interface. Further, a plotobject manages the plots interface. Components also include a transformobject 42, the purpose of which is to instantiate the particularfunction that the component is to perform.

[0036] Each component has access to the native operating system only byinterfacing through the Operating System Application ProgrammingInterface, OSAPI, 42 so that regardless of the particular computer oroperating system used, the component operating system interactions aretransformed to that of the particular computer and operating system.

[0037] In operation, the system described in FIGS. 1 and 2 operates asfollows: For a particular signal processing application a systemdesigner or application engineer first constructs a Plan 18. A Plan is apreformatted file representing a schematic of the configuration of thevarious components to be used to solve a particular signal processingproblem. It defines components, their interconnections andinterconnection communication methods, and initial parameters to controlcomponent activity. Components may be assigned to particular computers,useful when certain computers have input/output interfaces withparticular hardware such as signal digitizers required by the specificcomponent. Optionally, the Framework Manager will assign components tocomputers at run time. The plan is prepared separately based on taskingfor the system.

[0038] On system boot-up the Framework Manager is loaded and started.The Framework Manager starts a process thread that monitors requestsfrom Outside Application Programs 50 which seek to task or control thesystem. Once any outside application sends a message to a predefinedport, the Framework Manager accepts it and establishes an identity andreference for that application.

[0039] As each computer in the system boots up and comes on-line, theProcessor Manager program is loaded and started on each participatingcomputer in the system. Each Processor Manager broadcasts a UDP packetto register with the Framework Manager indicating that it is present andready to accept components. This message is received by the FrameworkManager, which acknowledges each processor manager. As the FrameworkManager establishes communications with each Processor Manager itdevelops a list of all the computers having a Processor Manager. Thesecomputers with Processor Managers are the available processing assets.

[0040] The Outside Application requests that the Framework Manager loadthe pre-constructed plan for operation. Typically more than one plan canbe in operation at the same time in the same system. In fact multipleplans can share components provided the identities of those are the samein both plans.

[0041] The Framework Manager analyzes the Plan and deploys theparticular components onto computers 24 and 26 as dictated by the Planand the available computers. This is accomplished by the FrameworkManager passing the name or names of the component or components forthat computer to Processor Manager 20 or 22 on that computer. It will beappreciated that one or more of the many processors in the system mayhave failed and therefore their Processor Manager isn't able to registerwith the Framework Manager so the plan can be configured around thefailure. Each Processor Manager then downloads the requested componentsfor its particular computer. The components then register with theProcessor Manager that in turn tells the Framework Manager that thecomponent is loaded. The Framework Manager maintains a list ofcomponents and their locations. From time to time, for example everysecond, the Processor Manager sends a message to each component deployedon its computer to determine whether each component is still functioningnormally. Failed components are unregistered and the Processor Managernotifies the Framework Manager that in turn logs the condition andnotifies the outside application.

[0042] The Processor Manager starts the execution of component 12 andthis occurs for each of the components identified in the Plan.

[0043] The Framework Manager also analyzes the Plan and identifies theparameters for the particular components. The Framework Managercommunicates via parameter interface 38 in setting the parameters forthe particular component to the correct default values as identified inPlan 18. Again, this occurs for each component in the Plan.

[0044] Next, the Framework Manager analyzes the Plan and identifies theconnection or connections between the output ports 36, outPorts, of thecomponents and the input ports 34, inPorts of the components. Thisconnection-based communication mechanism is peculiar to signalprocessing where streams of data are passed between the components toperform the aggregate system processing required. The Framework Managerlooks in its processor list and obtains the identity and reference forthe source and destination components. The connection is establishedbetween the output port and the input port by the Framework Managercommunicating to the output port 36 a list of destinations which are theidentities of the input ports on each of the components that are to beconnected. To do this the Framework Manager obtains the input portreference from the destination component and the output port referencefrom the source component. The port types are compared against the Planto ensure validity. If they are valid, the Framework Manager tells thesource component to connect its output port to the input port of thedestination component. The output port then sends a message to the inputport instructing it to accept data or events from the particular outputport. This again is repeated for each connection specified in the Plan.Using this method it is possible for an output to be received bymultiple input ports and for a single input port to listen for data orevents from more than one output port. Note that these connections areestablished at runtime. These connections may also be removed andreestablished from one component to other components, hence, making thesystem reconfigurable at runtime.

[0045] Various methods for communication are available within the systemand represented by the communication fabric 14. Physical connections,including busses, point to point connections, switched data fabrics, andmultiple access networks are abstracted by logical layers in the systemso that several logical connection types are available for communicationbetween components. In one embodiment, the default specifies remoteobject method calls via a real time object request broker, ORB. The ORBcomplies with the industry standard Common Object Request BrokerArchitecture, CORBA and is implemented by an off-the-shelf product. Thisselection is in keeping with the underlying object-oriented architectureof the system, but can be changed. Other communication means includesockets, which are supported by the target operating systems, and thenative communications protocols of the switched fabric interconnectsbeing used. One example is GM over Myrinet. The Plan defines thecommunication type and that type is sent to the ports when thecommunications are established as defined above.

[0046] Finally, when all the deployment and connections are completed,the Framework Manager starts each of the components using the startmethod on the component interface of each of the components 12. Uponinvocation of the start method, the components commence processing anysignals or events arriving at the component input port or ports and mayoutput signals or events from output ports.

[0047] If the parameters of a component need to be changed, OutsideApplication Program 50 first needs to determine the availableparameters. Via the ORB it calls the component to request definition ofits parameters. The component returns the available parameters. Theoutside application can then call the component to request currentparameter values, change the parameter values, or register to benotified when parameters are changed by some other means, ie. anotheroutside application. Then when parameters are modified the componentnotifies all registered applications of the change. When it is finishedthe outside application calls the component to unregister fornotifications.

Components

[0048] The component, itself an executable program, has requiredinterfaces as shown in FIG. 2, namely an input port 34, an output port36, parameters 38, plots and statistics 40. These interfaces are managedby objects in one embodiment as shown in the standard Unified ModelingLanguage, UML, class diagram of FIG. 3. The specific applicationcomponent 51 has an input port object 52 which manages the input portinterface; an output port object 54 which manages the output portinterface; a parameterSet object 56 which manages the parameters; aStatistics ParameterSet object 58 which is another ParameterSet thatmanages the statistics interface; and a ComponentPlot object 60 whichmanages the plots interface. Components also include a Transform object62, the purpose of which is to implement the particular function thatthe component is to perform. The statistics and parameters are part ofthe Component object 64 which provides control for the overallcomponent.

[0049] Each of the components is similar in that it performs a cohesiveprocessing step and meets the same interface. In addition to requiringthat each component meet this defined interface, the classes that defineobjects that manage the interfaces, input port class, output port class,parameters class, and plot class, all inherit their underlyingcapabilities from the corresponding base classes. The base classesprovide a guaranteed interface outside the component and provide defaultuseful functionality. This reduces the amount of specialization aparticular software developer is required to create in order to have afully functioning component.

[0050] The transform is an object that performs the required signalprocessing work. These are generally different for each componentproviding the specialized transformation of data that is done as part ofthe signal processing. There can be one or many of the transforms ineach component.

[0051] However, the basic form of each these objects which together forma component, input port, output port, component, transform, parameters,statistics, plots, is the same and they are guaranteed to be compatiblewith the interface because they inherit from the base classes. The inputport base class provides an interface to receive data or events. Thecomponent base class provides an interface to the framework and theProcessor Manager for identification of the basic control of transformsand the ports. The transform base class provides a simple interface tobe used by the component developer. The plotting base class providesengineering and plotting interface used typically for debugging andanalyzing problems in the components. Using the plotting interface,arrays or vectors of numbers in the memory of the component may berendered as signals graphically. The need for this visualizationcapability is unique to signal processing. The output port, again,provides the means of outputting signals from the component using commonmechanisms.

EXAMPLE

[0052] Each component developed to be interoperable, is developed byextending the base classes for the input port, output port, component,transform, and plots, and using the parameters class. Referring to FIG.4, a simple example component, the TMP component is presented. Each ofthe base classes are extended for the particular specialized additionalcapability required for the particular component.

[0053] Note: for purposes of illustration, and as one example of apractical embodiment of the subject invention, the C++ languagerepresentation for methods is used. Other embodiments of this inventionmay use other object-oriented programming languages, such as JAVA. Thespecific method names identified herein are only as an example of oneembodiment of this invention.

[0054] With respect to the input port, the base class for the input portis the inPort class. InPort is used by the component writer and isextended for the particular component. In the case of the TMP component,the tmpDataInput and TmpEventInput classes each extend the inPort baseclass. The purpose of the input port is to accept signal data or eventsinto the component. The inPort class has a number of methods that thecomponent writer uses and extends. Signal data or events are decomposedinto packets for transmittal across the data communication fabricbetween output ports and input ports. The input port accepts three typesof data packets that are essential for signal processing. These consistof headers and a payload. The headers provide auxiliary descriptivedata, so-called side-channel data representing where, when and how thedata was collected, and possibly processed. The first two types of data,shorts and floats are two types of signal data where the values in thisdata represent sampled signal data. Real or complex data may be passed.The third type of data is data which represents events, typicallyprocessing results which are representative of single action activitiesin time, which serve as triggers for subsequent signal processing.

Component Inputs

[0055] The inPort base class has methods for initialization andshutdown. The constructor InPort( ) and destructor InPort( ) areextended by the component developer to become the particular inPort thatis used for the particular component. In the example, these extended orspecialized methods are TmpDataInput( ) and ˜TmpDataInput( ), for theTmpDataInput class, and TmpEventInput( ) and TmpEventInput( ) for theTmpEventInput class. The constructor is used to create all the requireddata structures for a particular object of class inPort. Likewise thedestructor is used to delete them. Methods are provided for messageregistration permitting the component to identify if it wants to receiveincoming signal or event packets, which are registerForHeader( ) andregisterForEvent( ), registerForFloat( ), and registerForShort( ). Untilthere is registration, no data is passed. The methods for registrationfor messaging are generally not overwritten, but the base class methodis used directly, as in the example. These methods generally provide allthe essential functionality needed by the port. Methods are alsoprovided for message buffer management: getFloatStruct( ),getEventStruct( ), getZeroCopyFloatStruct( ) anddestroyZeroCopyFloatStruct( ), which allow the extended component tospecially manage memory for incoming packets. Typically, the methods formessage buffer management are used directly as inherited from the baseclass. However, these may be overloaded by the component writer forspecial customized buffer management. There are methods for the receiptof messages: acceptHeaderPacket( ), acceptFloatPacket( ),acceptShortPacket( ), acceptEventPacket( ). These methods must beoverloaded by the component, and generally are the entry point for thesignal processing algorithm software. These methods are invoked by theinput port upon receipt of the packet message at the framework interfaceof the input port, providing of course the appropriate registrationmethod has previously been invoked. These methods execute the signalprocessing, typically by making a method invocation of a method in someobject, often the transform object, that will actually perform thesignal processing. In the example, the acceptFloatPacket( ) methods ofTmpDataInput invokes the acceptDataPacket( ) method of the object ofclass TmpTransform. In the example, the acceptEventPacket( ) methodinvokes the acceptEventPacket( ) method of the controller, the TmpCntlclass, to set the attribute dataEnable of the controller. For additionalutility there are miscellaneous methods used by a component developerand the Framework Manager. These include setPortName( ) getPortName( ),which allows the components to set and retrieve an identificationcharacter string for the input port. The method getExpectedInputType( )allows an application to query the inPort to see what type of data is itexpecting to receive. Likewise the method, setExpectedInputType( )establishes that. The method getBytesPerSecond( ) allows objects withinthe component to obtain the amount of data passing through the inputport. These miscellaneous methods are generally not overloaded by thecomponents developer as they provide all the required functionalitydirectly from the base classes.

[0056] The above methods are common to all the signal processing and areused by the component input port to launch the signal-processing withinthe component. It will be appreciated that the few data types acceptedand processed by the inPort base class accommodates all of the inputsignals that one would expect to receive in a signal processing system;they are reused no matter what type of specialized signal processing isprovided by the transform within the component.

[0057] The input port also interfaces with the framework to actuallyreceive the communication of data or events from the output port of someother component. This framework side of the interface has anacceptFloatPacket( ), acceptShortPacket( ), and acceptEventPacket( )method. In one embodiment, these exterior methods are implemented asmethods of interface classes in IDL, the interface definition languagefor CORBA.

[0058] Additionally, this framework side interface has a method calledaddConnection( ) point which allows for connection-based communicationmechanisms that establish a virtual connection from output port to inputport along with an associated protocol handshake, as part of thecommunication link establishment sequence, when required by thecommunications mechanism.

Component Control

[0059] With respect to the component base class, the purpose of thecomponent base class and the component, which is extended from thecomponent base class, is to control the operation of the componentitself. In the present example, the class TmpCntl extends the base classComponent. Generally, this class is a singleton object, that is only oneper component. The functionality of the extended component includes theinitialization of the component, the setting up of the input ports, theoutput ports, the parameters and connection to the Processor Manager.The extended component class initializes the number of input and outputports needed and provides the start, stop, and shutdown mechanisms forthe component.

[0060] A number of methods must be defined in the class extended fromthe component base class. These include the constructor and destructor,in this example TmpCntl( ) and ˜TmpCntl( ). The component base class hasmethods to manage any data input/output activity. The start( ) method ofthe Component base class is overloaded in start( ) of TmpCntl class.This method is invoked when the component may emit data and initiatesignal processing. Similarly, stop( ) is the method that is invoked bythe framework to indicate the component is to stop emitting data. TherequestOutputPort( ) method performs any necessary processing when theframework requests the creation of an additional output port. Thecomponent may either extend this, in that case adding the functionalityor creating the new output port, or as in the example TmpCntl, may notoverload this method if the component writer desires not to support thisfunctionality in the component. The shutdown( ) method must beoverloaded to clean up or stop any threads from being started and toremove any data structures created by new( ) or other similar memoryallocation mechanism.

[0061] The method for getName( ) must be overloaded by the particularcomponent, as is done in the example TmpCntl. This method returns aunique identifying string for the component. The methods to update thecomponents statistics called update component statistics is alsooverloaded and methods to update components called parameters is calledupdate parameters.

[0062] In the component base class there are non-virtual methods thatare used un-extended from the component base class, as they provide toall the necessary functionality. These methods of the component baseclass include initialize( ), which is used to indicate anyinitialization is complete. The method getComponentID allows objectswithin the component access to the unique identifier for the instance ofthe component. A method sendMessage( ) is provided that is independentof operating system, compute platform, or available input/output devicesto indicate error conditions. This method sendMessage( ) is used to senderror messages to the Processor Manager, the Framework Manager and allwho have registered to receive these error messages. Methods areprovided to manage the input ports and output ports typically part of acomponent, and have associations with the extended component class.getInputports( ), getOutputPorts( ) return lists of the current inputports and output ports of that particular component. The methodsaddInputPort( ), addOutputPort( ), deleteInputPort( ) anddeleteOutputPort( ) modify these lists of current input and output portsfor the component. The component base class has a methodgetParameterSet( ) which allows objects in the component to have accessto the parameter set class that controls component behavior. See belowfor a detailed explanation of the parameter set object.

[0063] Components have statistics allowing visibility at run-time to theprocessing operation of the component. Statistics are actually parametersets that are output only, that is they do not permit changes to valuesexternal to the component. They provide a convenient mechanism for thecomponent to present internal data to outside a component due to theirself describing mechanism. Statistics are maintained within thecomponent and may be queried and may be emitted periodically. Thecomponent base class provides methods to manage the statistics. Thestatistics typically represent information about the processing rate oreffectiveness, such as samples processed per unit time, number of newsignals detected, or other information germane to development andoperation of signal processing systems. These methods includegetComponentStatistics( ) providing access to the parameterSet objectwhich is serving as the statistics object. During initialization,objects within the component may invoke the methodaddComponentStatistic( ) for each desired statistic, likewise duringdestruction the component invokes deleteComponentStatistic( ). Themethod sendComponentStatistics( ) sends the statistics to all objectsthat have registered. The component extends the component base classmethod updateComponentStatistics( ) to compute any new statisticsvalues. Typically this is invoked just prior to sendComponentStatistics(). A set of utility methods to manage the update timing of statistics isprovided. The methods setStatisticsRefreshInterval( ) andgetStatisticsRefreshInterval( ) establish and query the time betweenupdates. The method statisticsRefreshRequired( ) is provided that thecomponent invokes to test if the statistics refresh interval has a gainexpired. In typical operation, if this method returns true, theupdateComponentStatistics( ) and sendComponentStatistics( ) methods areinvoked. Additionally, a convenience method,getLastStatisticsUpdateTime( ) is provided that permits objects withinthe component to ascertain when the last statistics update wasperformed. These methods offer a multiplicity of options for thecomponent developer to manage statistics generation and reporting.

[0064] The component base class has as an attribute, a ComponentPlotSetobject, which is a list of ComponentPlot objects. These plot classeswill be described below. The component base class has an access methodto the componentPlotSet, plots( ).

[0065] The component interfaces with the framework to receive methodinvocations to control the component, and to produce informationrequested of the component by the framework or outside applications. Inone embodiment, these exterior methods are implemented as methods ofinterface classes in IDL, the interface definition language for CORBA.These exterior interfaces for the component include getting componentattributes: getComponentID( ), getComponentName( ), and getHostName( ).The framework side interface to the component has the following methods:start( ) which starts the component operation, eventually invokingstart( ) on the component, in the present example on TmpCntl; stop( )which the framework uses to command the component to stop its operation,eventually invoking stop( ) on the component, in the present example,TmpCntl; shutdown( ) which the framework uses to command the componentto prepare for shutdown and delete threads and to delete datastructures, eventually invoking shutdown( ) on the component, in thepresent example on TmpCntl. Message logging is managed byenableMessageLogging( ) and disableMessageLogging( ) which are used todirectly connect the sendMessage( ) from within the component to theframeworkManager and any other applications that have registered forerror reporting. Graphical plotting applications outside of thecomponent may invoke the getPlots( ) method, returning a list of plotsthe component has created and registered.

[0066] This framework interface to the component has access methods tothe input and output ports. These access methods getInputport( ) andgetOutputPort( ) return the port, if one exists, given a name string ofcharacters. Lists of input ports and output ports are available usingthe getInputports( ) and getOutputPorts( ) methods.

[0067] The parameters that control the behavior of the component areavailable to the framework and outside applications via thegetParameter( ) method, and are settable via the setParameter( ) method.The definitions of the parameters are available via thegetParameterDefs( ) method.

[0068] The statistics available within the component are availablerepresented as parameters via getCurrentStatistics( ) and thedefinitions are available via the getstatisticsDefinitions( ) methods. Acallback is established to request periodic statistics updated by thecomponent by invoking establishStatisticsCallback( ), and may becanceled by invoking cancelStatisticsCallback( ).

[0069] The requestOutputPort( ) method allows the framework to requestthe component to create a new output port on demand, and calls therequestOutputPort( ) method of the component, if overloaded. ThereleaseOutputPort( ) method likewise will request the destruction of anynewly created output port that was created this way.

Component Outputs

[0070] With respect to the output port interface, the OutPort base classprovides two required functions inside the component. First, is theemission of the signal or event data that was just processed by thecomponent. Again, this is in the form of float data or short data with aheader or event data, for instance, when the signal-processing componentis providing such detection and the detection actually occurs from thesignal data that is fed into it. The second functionality of the outputport is to manage parameters that are used to control the transformassociated with the output port. In the example, the TmpOutput classinherits from the OutPort class. The parameters of this output portcontrol the behavior of the TmpTransform class, which is associated withthe TmpOutput class. The constructor OutPort( ) and destructor ˜OutPort() are extended by the component developer to become the particularinPort that is used for the particular component, In the example theseextended methods are TmpOutput( ) and TmpOutput( ). The OutPort baseclass has other methods that typically are used without extension,including getcomponent( ) which allows the application to get thereference of the component that contains the outport, and getPortName( )and setPortName( ), a string used to identify the outport to theFramework Manager. The send( ) method is the method invoked by thecomponent or transform within the component to actually send the datafrom the output port of one component to the input port of anothercomponent.

[0071] There are methods to manage the output port parameters. Theseparameter controls the behavior of the transform associated with theoutPort class. This includes the method updateParameters( ), which is amethod of the extended outPort class, such as TmpOutput in the presentexample. This method is invoked when parameter values are changed, andcontains the specific behavior programmed by the component developer tooccur upon changes in parameters of the OutPort. The methods of the baseclass getParameterSet( ), and setParameterSet( ), are used by thecomponent or transform to define the set of parameters typically duringconstruction of the OutPort object, and to get the current parameter setobject.

[0072] The output port also has an interface to the framework toactually communicate data or events to other components, and to managethis communication, plus for the management and control of parameters ofthe transforms associated with the output ports. In one embodiment,these exterior methods are implemented as methods of interface classesin IDL, the interface definition language for CORBA. The interfaceincludes methods to get the port name get_portName( ), get the emitteddata type, get_dataType( ), and get the list of inputPorts connected tothe output port, getinputConnections. The parameters of the output portare obtained from outside the component using the getParameters( )method. The definitions of the parameters of the output port areobtained from outside the component using the getParameterDefs( )method. Outside applications or the Framework Manager change values ofthese parameters using the setParameters( ) method. The methodconnectInput( ) is the mechanism the Framework Manager uses to establishthe connections from the output port to the input port of the othercomponent. The disconnect Input( ) method removes the connectionestablished by the connectInput( ) method.

Parameters

[0073] The parameters are now described. Parameters are self describingentities that control the behavior a component or of a transformassociated with an output port. Parameters are consistent over the lifeof the component that is, they exist in the beginning of the componentuntil the component destructor is called. Parameters always have thedefault values, and the values of parameters can be modified after theyare set. Again, parameters are externally observable, that is,observable by the Framework Manager and outside applications, as well asbeing observable internally to the component.

[0074] The parameters are managed by the ParametersSet class, which is acontainer class, which can store individual parameters as parameterrecords. The ParameterRcd objects are stored in the parameterSet. EachParameterRcd describes the single parameter that controls the signalprocessing behavior of the transform or of the component. This behavioris controlled at runtime. By using this parameter interface, there is acommon mechanism for all components in order to modify the behavior ofthe component regardless of the detailed parameters. The ParameterSetclass is not extended but is used unchanged. It is used in its entiretyto provide all its capabilities simply by changing the values atruntime. Each individual ParameterRcd object can store one of threetypes of data, integer, double or a string. Each ParameterRcd object hasthe following five entities: the current value, the default value thatexists when the component is first constructed, the minimum acceptablevalue, the maximum acceptable value, and a list of acceptable valueswhere acceptable values can be enumerated, instead of being controlledby a minimum and maximum. If an attempt is made to set the value of aparameter outside of these minimum and maximum limits, an exceptionautomatically occurs and the value is not set within the component.

[0075] The following methods are provided to control objects of classParameterSet, which is the container of multiple parameter records.These methods include methods used for accessing the parameters,getIntParameter( ), getStringParameter( ), getDoubleParameter( ),getName( ). The method getIntparameter( ) obtains the value element of aParameterRcd of a specified name in integer format. The methodgetStringParameter( ) obtains the value element of a ParameterRcd of aspecified name in string format. The method getDoubleParameter( )obtains the value element of a ParameterRcd of a specified name indouble precision floating point format. The method getName( ) returnsthe name of the ParameterSet established typically by the constructor ofthe component. There are complementary methods to set the parameters:setName( ) establishes the name of the parameterSet, setParameter( )establishes the value of the ParameterRcd identified by the namespecified. A convenience method is provided for the component or otherobjects within the component, to fetch parameters modified by theframework or other outside application, fetchModifiedValue( ) andfetchNextModifiedValue( ).

[0076] There are methods provided on the ParameterSet used to add,update and delete parameters. These are typically used during theconstruction or destruction of the component. The addParameter( ) methodaccepts new parameters by name and default value, and is used bycomponents to create unique parameters for a particular signalprocessing application. The method addEnumeration( ) accepts enumeratedvalues such as “A”, “B”, “C”, or “D” to be added to a specifiedparameter. The method removeParameter( ) allows for the parameter to beremoved. This is typically used during the destructor. There are methodsused to reset parameters to default values, resetAll( ) and reset( )which take the name of the parameter. This allows the component toreturn to the default value rather than a currently set value, a valuethat was set by the Framework Manager. The updateParameterSet( ) methodtests each value of each parameter to ensure it is within bounds priorto setting the value of the parameter.

[0077] Each ParameterSet is composed of ParameterRcd objects. AParameterRcd class has a number of methods that are used to manipulatethe parameter record itself. The constructor for the ParameterRcd objectcreates the object. The method getDataType( ) retrieves the data type ofa particular ParameterRcd object. Additional methods on the ParameterRcdclass include getAcceptableValues( ) which returns a vector ofacceptable values set during the construction and creation of theParameterRcd. The getName( ) methods returns the name of the parameter,getDoubleParameter( ) returns the value of the parameter as a doubleprecision floating point number, getStringParameter( ) returns the valueof the parameter as a character string, and getIntParameter( ) returnsthe value of the parameter as an integer. The method getDefaultValue( )returns the default value of the particular parameter record. The methodSetParameters( ) attempts to set the value of the parameter, firstchecking the minimum and maximum acceptable values, or the permittedenumerated values. The methods getMaxValue( ) and getMinValue( ) returnsthe maximum and minimum acceptable values of the parameter, which wasset when the ParameterRcd was constructed. The method getValue( ) getsthe actual and current value of that ParameterRcd.

[0078] The component interfaces with the framework to set and get theparameters of components or output ports. In one embodiment, theseexterior methods are implemented as methods of interface classes in IDL,the interface definition language for CORBA. These exterior interfacesfor the parameters interface to the framework is through the componentbase class. The parameters that control the behavior of the componentare available to the framework and outside applications via thegetParameter( ) method, and are settable via the setParameter( ) method.The definitions of the parameters are available via thegetParameterDefs( ) method. Upon a setParameter( ) invocation, theparameter is checked and the updateParameters( ) method of the extendedcomponent base class is invoked. In the present example that method isthe updateParameters( ) method of TmpCntl. The component updates anyattributes and performs any changes in behavior as the parametersdictate.

Transform

[0079] What is now described is the transform base class. The transformbase class is extended by the component developer. The transform is oneinstance of the signal processing performed by the component. Thetransform class is where the signal processing work gets done inside thecomponent. In the present example, each object that will perform thesignal processing is of class TmpTransform, which inherits fromTransformBaseClass. This encapsulates the signal processing involvedinside the component. At least one of the transform base class methodsacceptDataPacket( ) and acceptEventPacket( ), must be overloaded by thecomponent developer, as is done in the present example TmpTransformclass, having the acceptDataPacket( ) method which is where the signalprocessing code goes. When data arrives at the component, it arrives inthe input port, on the framework side of the interface, invokingacceptFloatPacket( ), for example if the data type is floating pointdata representing signal samples. The component extended inport, in theexample TmpDataInput, calls the acceptFloatPacket( ) method. This methodtypically calls the acceptDataPacket( ) of the extended transformobject, in the example TmpTransform. The acceptDataPacket( ) of theextended transform object performs the signal processing work. When thesignal processing work is completed for that packet, the transformobject invokes the send( ) method on the output port. The transform baseclass has minimal functionality, but is extended and is where the signalprocessing work is inserted by the component developer. All the otherrequired interfaces and infrastructure support are provided by theextended inPort class which, again, is providing input data in properformat as it arrives.

Plots

[0080] With respect to the Component plot interface, it should be firstmentioned that traditional software development tools do not provideuseful representation of vectors or arrays of sampled data such that asignal processing engineer can quickly visualize the internalfunctioning, or perhaps more correctly, the malfunctioning of thecomponent software during development. The plot class is an interface isto permit the visualization of the data in a graphical format.Specifically for signal processing, this is the software analog of anoscilloscope probe.

[0081] The plot capability includes the ComponentsPlot set class and aComponentPlot. The ComponentPlotSet is a container class ofComponentsPlots which will be described first. The Component base classhas one ComponentPlotSet. The ComponentPlot provides updated graphicalplot of data within the component used for signal processing debuggingand diagnostics. These plots can be viewed with an external application.The ComponentPlot class is extended to create a plot class specificallyfor that component. In the example it is class TmpPlot. Each extendedComponentPlot has a parameter set to define and control the behavior ofthe plot itself. This interface is similar to the parameter set of thecomponent, and in fact, uses the same class parameterSet. The extendedComponentPlot has a method for getting the plot name: getPlotName( ).The extended ComponentPlot class also has methods to manage the plotsupdates: selectPlot( ) which is called when the external plottingapplication requests the plot, and refreshPlot( ) which is calledinternally by the component and provides the rendering of the plot. TheselectPlot( ) and refreshPlot( ) methods are completed by the componentdeveloper to render and populate the plot using plot tool interfacemethods, which will be described later. The ComponentPlot base class hasa method to obtain the parameters of the plot: getParameters( ), and amethod to obtain the plot tool interface that is the reference of theexternal application via getPlotTool. The ComponentPlot base classmethod refreshRequired( ) which tests whether a timer has expired andwhether it is time to render the plot and the method setRefreshInterval() which establishes how often the plot should be plotted.

[0082] The ComponentPlotSet class is the container of ComponentPlotobjects. The methods on the ComponentPlotSet provide access methods byname: getPlot( ), getParameters( ), refreshRequired( ), refreshPlot( )and selectPlot( ) and cancelPlot( ) for an entire container of plots.These are similar in functionality to the similarly named methods on theindividual ComponentPlot class. The ComponentPlotSet class also hasmethods for adding a ComponentPlot object once created: AddCPlot( ), andfor removing a ComponentPlot object: RemoveCPlot( ).

[0083] The component plot interface also interfaces to an externalgraphics plotting application for the framework. This interface istypically used by the selectPlot( ) and refreshPlot( ) methods on theextended ComponentPlot object, in the present example, an object ofclass TmpPlot, to render plots on the external graphics plottingapplication upon request of the external application. From within thecomponent, this interface is constant. This interface has a method toadd and initialize a plot and a method to remove a plot: addPlot( ) andremovePlot( ). A method setPlotTool( ) is provided to specify whichinstance of an external graphical plotting application is to be used,given a handle, the format of which is a function of the underlyingcommunications mechanism used in the embodiment of the framework. Amethod is provided to add and initialize a text panel on the externalplotting application, addTextPanel( ), to clear text from the renderedpanel, clearText( ), and a method to write text to the panel, writeText(). Methods are provided to plot a vector of signal data as a function ofindex, plotfx( ), and to plot a pair of vectors of signal data, onevector being the abscissa, and one being the ordinate of the point to berendered, plotxy( ). As described, the external graphics plottingapplication interfaces with components to receive commands to renderplot information graphically. In the preferred embodiment, thesecommands are implemented as methods of interface classes in IDL. Thesemethods have the same nomenclature and arguments as the methods justdescribed.

[0084] The component interfaces with the framework to manage theplotting functionality. In one embodiment, these exterior methods areimplemented as methods of interface classes in IDL. These exteriorinterfaces for the plots interface to the framework is through thecomponent base class. The plot interface on the exterior of thecomponent consists of a method which an external graphics plottingapplication can invoke to query each component for all the possibleplots that it can provide, getAvailablePlots( ). An external graphicsplotting application can also query the component for the parametersthat may control the plots, parametersForPlot( ). When an externalgraphics plotting application needs to commence rendering the plot, itinvokes the selectPlot( ) method on the exterior interface, whichinvokes the selectPlot( ) and refreshPlot( ) methods on the extendedComponentPlot object, in the example, an object of class TmpPlot. Thesemethods use the rendering methods described above, such as plotfx( ), torender plots on the external graphics plotting application. When anexternal graphics plotting application no longer requires the renderingof signal data, it may invoke the cancelPlot( ) method which indicatesto stop rendering the particular plot.

Framework Manager

[0085] Having described the base classes and their application to anexample component, attention.is now turned to the Framework Manager.

[0086] It will be appreciated that the entire functionality of theFramework Manager is captured by the interface, which will be described.

[0087] The Framework Manager is the root object for the system. It is asingleton in that there is one and only one in each system using thiscomponent and framework architecture. The responsibility of theFramework Manager is to keep track of all processors and components. Itallows an outside application or applications to identify and locate theprocessors and components executing on those processors. The FrameworkManager's principal role is to manage and deploy the Plan, the Planbeing the location-of the components on the computers, componentinterconnection, and the parameters that control component behavior.These three things, in combination, define the system itself, includingits operation and its ultimate function as a signal processor.

[0088] Framework Manager has a method for the Processor Manager toregister, registerProcessor( ), used when the each Processor Managerstarts operating, used to indicate to the Framework Manager thatprocessor is available for use in the system. A method is provided forany outside application program to get the list of Processor Managerscurrently registered, getProcessors( ). The Framework Manager has amethods to obtain a list of which components are currently executing oneach processor, getProcessorDetails( ). A similar method is availablethat identifies the processor executing a particular instance of acomponent, getProcessorForComponent( ).

[0089] A number of methods of the Framework Manager provide control andstatus information relative to the component itself: a method toregister a component which a Processors Manager invokes when thecomponent has been loaded and is ready to run, registerComponent( ); andsimilarly unregisterComponent( ) which is called by the ProcessorManager when the component has shut down; and a method to get the listof components matching certain text strings called getComponents( ).Likewise, a-similar method findComponent( ) returns a list of componentsmatching certain names and parameter name, value pairs.

[0090] There are a number of methods the Framework Manager provides thatare used for the deployment of components. They are used by an outsideapplication in preparation of a Plan. The first is allocateComponenID( )which ensures a unique component identity on the existing system. TheenterPlan( ) method accepts a Plan as a formatted data structure to beentered and deployed, and connections established and parameters set onthe particular components identified in the Plan. A similar methodenterPlanAsText( ) is also available that accepts the Plan in a humanunderstandable text format. Similarly, enterPlanAsFile( ) allows a filename to be specified and the Plan read from the specified file. Onceentered into the Framework Manager, the Plan may be started. A methodcalled startPlan( ) starts all the components in a Plan with thespecified name. A method stopPlan( ) stops all the components in a Planwith the specified name. The method removePlan( ) shuts down, invokesthe shutdown( ) method on each component, and unloads all thecomponents, given the specified Plan name. The method listPlan( )provides a list of all Plans that have been deployed or entered into theFramework Manager. The placeComponentMethod( ), which allows anindividual component to be placed in addition to that of the Plan. TheremoveComponentMethod( ) which removes an individual component. ThemakeConnection( ) method which connects between the output port of onecomponent and the input port of another component. This can be doneindividually in addition to those identified in a Plan. Likewise,removeConnection( ) method removes an individual connection.

[0091] It will be appreciated that each of these methods will be used toprovide various configuration and reconfiguration at runtime of thesystem. In addition, the Framework Manager has an extensible interfaceto a configuration manager object, not included in this system, whichallows an external algorithm to be used for automated deployment, andconnections of components, in some optimized manner.

[0092] In summary, the Framework Manager allows one to configure andreconfigure the entire signal processing system to be able to add andsubtract functionality and reconfigure the entire system on the fly,thus to be able to provide differing signal processing functions withinthe same equipment suite.

[0093] In the configuration process the Plan is read by the FrameworkManager in one of its many forms as described above. The components areactivated on each of the processors specified each of the components areconstructed and are then connected with their initial parameter settingare set. When all that is completed, then each of the components havetheir start( ) method invoked, which then starts the processing andemitting of data out of the component.

[0094] To reconfigure, in the simplest example, a pair of components isdisconnected by the Framework Manager, the first component is shut down,another third component deployed, and this third component is connectedby connecting the output port of this third component to the input portof the second component. The third component is started and the systemnow operates performing a different functionality on the same equipment.

Processor Manager

[0095] As another integral component to the signal processing system asdescribed above, what is now described is the Processor Manager.

[0096] The Processor Manager program resides on each processor withinthe system. The Processor Manager program is automatically started oneach processor when-the processor boots up. The Processor Manager is anextension of the Framework Manager projected onto each processor. TheProcessor Manager loads and starts components at the direction of theFramework Manager, and reports the current processor status andutilization to the Framework Manager. The Processor Manager methodsinclude the method ping( ), which by invoking, the Framework Manager candetermined whether the Processor Manager is currently operating; and theregisterComponent( ) method in which a component executing on theprocessor invokes upon its construction to inform the Processor Managerthat the component is ready to process. The enableMessageLogging( ) andthe disableMessageLogging( ) methods are used by the Framework Managerto tell the Processor Manager to forward any error messages created inthe components using the Component base class method sendMessage( ) fromthe component to the Processor Manager, to the Framework Manager, andwhich then may be passed to an external application to display the errormessages. The listLoadedComponents( ) method provides a list ofcomponents currently loaded on the processor. The loadComponent( )method is used by the Framework Manager to request a particularcomponent be loaded on the processor managed by the Processor Manager.This is typically used during the initial deployment and configurationby the Framework Manager. The removeComponent( ) method is used by theFramework Manager to shutdown and unload the component from theprocessor managed by the Processor Manager. In addition, the ProcessorManager provides usage metrics, which may be used for optimization oranalysis of component deployment: the fetchMetrics method which returnsdata about the processor utilization and memory utilization.

[0097] While the subject system has been described in terms ofcomponents, base classes, a Framework Manager, and a Processor Manager,when it runs a particular signal processing task, it may involve thecommunication with outside application programs. Note that the outsideapplication programs can also be used for diagnosing the system. Outsideapplication programs are illustrated at 50 in FIG. 2 which function asfollows:

[0098] The outside application program interfaces to the parameter set,parameter record and the interface of the components changing individualparameters, which change the behavior of the components at runtime.Additionally, the outside application program can contain a plottingapplication used by the component plot class. This is referred to as theplot object.

[0099] The outside application can also change parameters of thecomponents. The outside application can graphically render the plotoutput as provided by the components and the component plots interface40. By changing the parameters on the component or the parameters of theoutput port, the behavior of the transform and component can be changedat runtime and the effect of those changes can be observed on thosecomponent plots which are returned to the outside application program.

Layered Architecture

[0100] Referring now to FIG. 6, the layered architecture for the presentinvention is shown. By a layered architecture is meant that objects ormodules of the system software are organized into sets referred to aslayers. When a module is part of one layer it can use any other modulein that layer directly. However, when a module in one layer must use thecapabilities in another layer it can only do so according to the strictinterface definition at the layer-to-layer boundary. Layers are used toreduce complexity by restricting relationships between modules therebyproviding independence between different parts of the system. The goalis to increase reusability and maintainability in software systems. Forexample, by layering the operating system interface, one ensures that achange in operating system does not affect the entire software system.

[0101] As illustrated in FIG. 6, particular computer hardware 88actually executes the computer code to run the signal processingapplication. Higher level software does not interact directly with thecomputer hardware, instead it interfaces through the specific OperatingSystem 86. Example operating systems which have been used forimplementing this system include Microsoft Windows NT, VxWorks, andLINUX. Since these various operating systems and others all havesomewhat different interfaces, the translation is isolated within theOperating System Application-Programming Interface, or OSAPI, layer 84composed of the OSAPI class.

[0102] The OSAPI provides platform-independent andoperating-system-independent methods to access the underlying operatingsystem capabilities. Thus the OSAPI layer is a translation from thenative operating system to a common interface used by the componentsregardless of the native operating system or native hardware platform.

[0103] These include but are not limited to methods to change specificdirectory or path, chdir( ) or fixPath( ); methods to start a task orperform a system call, spawn( ) and system( ); methods for environmentinitialization or host management, startup( ), getHostName( ), hostType(); and methods for swapping bytes and determining the so-called Endiantype of the platform, such as littleEndian( ), swap2 ByteData( ), swap4ByteData( ), swap8 ByteData( ) which provide platform independentoperation. Methods to handle time functions using seconds ormicroseconds such as getHighResTime( ), geTimeofDay( ), timeToText( ),sleep( ), usleep( ) may be used; and other methods to control processinginclude, taskLock( ), taskUnlock( ), contextSwitch( ) and to move data,fastestCopy( ). These are all independent of the underlying actualoperating system and allow the same source code to be used in multipleprocessor environments and operating system environments. Endiandescribes the ordering used natively by the machine in a multi-byteword. For example, a four byte integer in little endian representationhas the least significant byte placed first in memory and the mostsignificant byte placed fourth in memory. In big endian representation,the first byte in memory is the most significant byte; the third byte orthe fourth byte in memory is the least significant byte. This endianconversion, byte swapping and endian test permits interoperation betweendifferent types of computer hardware.

[0104] A Libraries layer 82 provides a standard set of calls for signalprocessing primitives such as Fast Fourier Transform FFT( ) and FiniteImpulse Response Filter FIR( ). The interfaces to these libraries isconstant regardless of the actual computer type being used to performthe computations. In one embodiment the interface to the components isprovided by the industry-standard Vector Signal and Image ProcessingLibrary (VSIPL). Most hardware vendors provide VSIPL libraries that areoptimized for their hardware platform.

[0105] The CORBA layer 96 provides default method for remote objectmethod invocation in one embodiment. CORBA stands for the industrystandard Common Object Request Broker Architecture and it is implementedby an off-the-shelf product. This selection is in keeping with theunderlying object-oriented architecture of the system, but can bechanged and so has been isolated in its own layer. Other communicationmeans include sockets, which are supported by the target operatingsystems, and the native communications protocols of the switched fabricinterconnects are also available within the distributed framework.

[0106] A Distributed Framework layer 94 consists of the FrameworkManager, Processor Managers and other objects and services which providethe infrastructure for operating the components in a system.

[0107] The Component Base Classes layer 92 provides most of the genericcapabilities needed by all components in the system. These base classesare described in detail above. This layer facilitates rapid developmentof components from direct reuse of much common software code. Byproviding the interface between the Specific Application Components 80and the interface from the Components 80 and the Distributed Framework94, it relieves the software component developer from the burden ofcomplying with these interfaces.

[0108] Specific interfaces are also defined between the Component BaseClasses, the Distributed Framework, CORBA, and the Outside Applications90 which control the system and receive the processing results. Examplesinclude the plot interfaces, parameters interface, and statisticsinterface from the component base classes, and the Framework Manager andprocessor manager interfaces as described above.

[0109] A program listing for the illustrated embodiment is provided inthe Appendix hereto.

[0110] Having now described a few embodiments of the invention, and somemodifications and variations thereto, it should be apparent to thoseskilled in the art that the foregoing is merely illustrative and notlimiting, having been presented by the way of example only. Numerousmodifications and other embodiments are within the scope of one ofordinary skill in the art and are contemplated as falling within thescope of the invention as limited only by the appended claims andequivalents thereto.

What is claimed is:
 1. A reconfigurable signal processing system usingan object-oriented component-framework architecture, comprising: atleast one software component for providing at least one signalprocessing function; at least one processor coupled to said componentfor executing the software of said component; a processor manager forcontrolling the operator of said procesor; a data fabric for providingdata communications between said processor and said software component;a plan for specifying the operation of said signal processing system;and, a framework manager for implementing said plan by deploying saidcomponent to said processor.
 2. The system of claim 1, wherein saidsignal processing system is a distributed system having multiplesoftware components and multiple processors such that there are multiplesoftware components on a distributed network which interconnectsselected processors with selected software components under the controlof said framework manager, said framework operating to establishplatform independence for the source code for said components such thatcomponents are hardware independent and may be added without concern asto compatibility with said processors in a plug-and-play fashion.
 3. Thesystem of claim 1, wherein said signal includes streaming data.
 4. Thesystem of claim 1, wherein said data fabric includes a network.
 5. Thesystem of claim 1, wherein said data fabric includes a switchedinterconnect.
 6. The system of claim 1, wherein said data fabricincludes a database.
 7. The system of claim 1 wherein the basicoperational capability of said software component is inherited from acomponent base class, whereby said software component can take advantageof previously developed software in said component base class.
 8. Areconfigurable distributed signal processing system using anobject-oriented architecture, comprising: a number of signal processingsoftware components adapted to be coupled to a processor utilizing alayered structure adapted to keep applications independent ofinfrastructure to permit coupling of a software component to a processorregardless of the type of component or processor, such that saidcomponents are interchangeable and platform independent to permit reuse.9. The system of claim 8, wherein said components are reconfigurable atrun time in accordance with a plan defining the identity and location ofcomponents used to solve a signal processing task.
 10. The system ofclaim 9, wherein said plan includes a list of said components, whatprocessor the components are located on, how said components andprocessor are interconnected.
 11. The system of claim 10, wherein saidplan includes initial parameter values.
 12. The system of claim 9,wherein said system includes distributed processors, a framework managerfor reading said plan and configuring said system to execute said planand a processor manager on each distributed processor to deploy andcontrol components, maintain status and interact with said frameworkmanager.
 13. The system of claim 8, and further including a data fabrichaving a platform-independent layered structure for connectingcomponents and processors in a platform-independent manner.
 14. Thesystem of claim 8, wherein components communicate with other componentsonly through framework-provided services.
 15. The system of claim 8,wherein said components inherit respective characteristics fromcomponent base classes that insure interface compatibility.
 16. Anobject-oriented signal processing system having software componentsexecuting on processors through the use of a distributed frameworkhaving a universal interface such that signal processing can be addedthrough the addition of software components without regard to theplatform on which said components are to be run.
 17. The system of claim16, wherein said components are developed using component base classesfrom which said components inherit their properties, said component baseclasses ensuring interface compatibility.
 18. The system of claim 16,wherein said components and processors are interconnected and run inaccordance with a plan.
 19. The system of claim 18, wherein said systemincludes a framework manager for interpreting said plan and fordeploying components on the processor specified by said plan such thatsaid framework manager configures said system and commences theexecution of the signal processing functions specified by said plan. 20.The system of claim 16, wherein all interface elements of said signalprocessing system have properties inherited from a respective base classso as to ensure interoperability of all of said elements.
 21. The systemof claim 20, wherein all of said components are reconfigurable atruntime.
 22. The system of claim 16, wherein said signal processingsystem includes a specialized operating system application programminginterface specified for said processor and said data fabric fortranslating from a common component interface to the native operatingsystem such that each of said components are made platform-independent.23. The system of claim 16, wherein each of said software componentsincludes an input port, an output port and a transform for processingdata on said input port and coupling the processed result to said outputport.
 24. The system of claim 16 wherein each of said softwarecomponents include well defined ports.
 25. The system of claim 24,wherein one of said ports is used for setting parameters for saidcomponent.
 26. The system of claim 24, wherein one of said ports is usedto generate statistics related to the operation of said components. 27.The system of claim 24, wherein one of said ports is used to permit thegeneration of plots of component operation in graphical form, thus topermit visualization of this operation of said components.
 28. Thesystem of claim 16, wherein each of said components has an interface torender graphical plots on an external program, and wherein saidgraphical plots represent one or more input, output, or intermediatesignals being processed by said component.
 29. The system of claim 28,wherein the interface that provides for the control of parameters thatcontrol the behavior of said components at runtime is self-describing,providing definitions of the parameters in addition to the values ofparameters.
 30. The system of claim 16, wherein each of said componentsprovides statistics on the internal signal processing operations of acomponent through a common interface.
 31. The system of claim 16,wherein each of said software components have input and output ports andwherein said input and output ports accept and emit packets representingstreaming signal and event data.